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(54) Tltie: SYSTEM AND PROCESS FOR ALLOWING WIRELESS MESSAGING 



(57) Abstract 

A bi-directional (and/or uni-directional) multiplexing 
messaging gateway (101) for wireless devices, such as for de- 
vices (130) using the Global System for Mobile Communication 
(GSM) wireless digital standard, or any other suitable protocols. 
Electronic messages may be transmitted over a wireless cormec- 
tion to, or to and from, a mobile phone (130), and maintain and 
facilitate all necessary housekeeping functions. Electronic mes- 
sages addressed to a mobile phone (130) may be received by 
the gateway (101) from the Internet (140), a LAN (120). or any 
other source, and routed to the appropriate mobile phone (130). 
Such electronic messages may be originated manually or may 
be automatically generated by specific computer applications, 
such as a scheduling program operating on a LAN (120). Like- 
wise, the user of the mobile phone (130) may reply to the sender 
of the original electronic message, whereby the gateway (101) 
of the present invention maintains the address of the sender and 
matches it with tiie reply so as to fiacilitate the forwarding of 
the reply to to correct address. The user of the mobile phone 
(130) may cause an electronic message received from a sender 
to be remotely routed to a chosen facsimile machine (150) or 
any other suitable destination. 
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SYSTEM AND PROCESS FOR ALLOWING WIRELESS MESSAGING 



Background of the Invention 



1. Field of the Invention 



The present invention relates generally to a system for providing wireless 
10 messaging, and specifically to a system for providing bi-directional wireless electronic 
mail. 

2. Description of the Prior Art 

Short Message Services are provided by operators of wireless communication 
systems today who have digital service available. Short Message Services, or more 
simply put "SMS", are messages delivered by the wireless network to a digital phone. 
There are three major digital standards commonly deployed throughout the US today; 
Code Division Multiple Access ("CDMA"), Time Division Multiple Access 
("TDMA"), and Global Systems for Mobile ("GSM"). 

Global Systems for Mobile ("GSM") is a specification that was written to 
provide a unified digital platform that all 12 countries of the European Community 
("EC") could use from one country to the next with the same phone. Other countries 
25 outside of the EC have adopted GSM as their preferred system specification increasing 
the volume of systems worldwide. The first systems went commercial in 1 993 in 
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Europe, while the first commercial GSM system in the United States went commercial 
at the end of 1995. 

GSM is similar to IS-54 TDMA (see below) in that it uses FDMA to separate 
RF carriers and TDMA to serve up to 8 users per channel. It was developed to provide 
a single European standard and to facilitate many new enhanced services and automatic 
:_roaming._Initially, GSM used t he 900 Mhz band but has now added two compatible 
standards: DCS 1 800 at L8 Ghz and PCS 1 900 at 1 .9 Ghz. TDMA (or D-AMPS) began 
life as a digital upgrade to the 800 Mhz AMPS network and is commonly referred to as 
IS-54. It employs the 30 kHz AMPS channel split into three timeslots with a separate 
control channel. The standard was upgraded to IS- 136 to include an integrated digital 
control channel and interband operability to 1900 Mhz. CDMA was developed to 
provide further capacity enhancements over the TDMA standards. It uses Direct 
Sequence Code Division Multiple Access to differentiate users on the same 1.28 Mhz 
frequency band. CDMA systems are currently operating at 800 Mhz and 1900 MHz. 

The US and other countries also decided that there was enough demand for 
wireless services in the marketplace to introduce more competitors into each market. 
The amoimt of new competitors has varied from country to country, but they have 
consistently used the higher frequency band in the 1900 MHz band. This new license 
area is generally known as Personal Communication Services ("PCS*'), and six new 
licensed providers have been introduced in each market throughout the US. The two 
existing operators are generally referred to as "Cellular" operators and operate in the 
800MHz band throughout the US. 



2 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO_985847eA1_L> 



wo 98/58476 




PCTAJS98/12536 



Summary of the Invention 



The present invention provides a bi-directional (and/or uni-directional) 
multiplexing messaging gateway for careless devices, such as for cellular devices using 
5 the Global System for Mobile Communication (GSM) wireless digital standard, or any 
other suitable protocols. Electronic messages may be transmitted over a wireless 

connection to, or to and fro m, a mo bile phone , and t he present invention maintains and 

facilitates all necessary housekeeping functions. For example, electronic messages 
addressed to a mobile phone may be received by the gateway of the present invention 

10 from the Internet, a LAN, or any other source, and routed to the appropriate mobile 

phone. Such electronic messages may be originated manually or may be automatically 
generated by specific computer applications, such as a scheduling program operating on 
a LAN. Likewise, the user of the mobile phone may reply to the sender of the original 
electronic message, whereby the gateway of the present invention maintains the address 

15 of the sender and matches it with the reply so as to facilitate the forwarding of the reply 
to the correct address. Finally, the user of the mobile phone may cause an electronic 
message received from a sender to be remotely routed to, for example, a chosen 
facsimile machine, or any other suitable destination. 

20 Brief Description of the Figures 

FIGS. 1-3 are block diagrams depicting various components of the present 
invention. 



25 



FIGS. 4-21 are flow diagrams depicting the operation of the present invention. 
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Detailed Description of the Invention 

5 A preferred embodiment of the invention is now described in detail. Referring 

to the drawings, like numbers indicate like elements throughout the views. 

r. Overall System 



10 In one embodiment, the present invention may be implemented as a Unix-based 

messaging gateway for Global System for Mobile Communications ("GSM") network 
operators. Of course, any other suitable communication protocol may be used as well, 
such as Code Division Multiple Access ("CDMA"), Time Division Multiple Access 
("TDMA"), or the like. FIG. 1 depicts an overall functional diagram showing the main 

15 components that may be utilized in implementing the present invention. 

With reference to FIG. 1, an overall configuration 100 is shown. The network 
operator components 110 may include a standard Short Message Service Center 
(SMSC) 102 module as well as a switch 103 for communicating to and from the 
20 transmission towers 131, and hence the mobile phones 130. The functionality 

performed by the present invention may be included within the.gateway 101, which 
may also form part of the network operator components 110. 

In one embodiment, the gateway 101 may comprise software running under the*^ 
25 Solaris Unix operating system, running on a Sun SPARC Ultra 2 machine, available 
from Sun Microsystems. The C+h- programming language (such as in the Sun 
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Neo Workshop) may be used to implement the software to implement the gateway 101, 
and the user interface may be implemented in Java, the tools for which are also 
available from Sun. Of course, any other suitable machine, operating system and/or 
development tools "may also be used. 

The gateway 101 may be connected to the Internet 140 (and/or other equivalent 
public private, data network) via line 141, which in one embodiment m a y comprise a 
DDS leased line, a standard telephone line, or equivalent, using any type of transport 
protocol (e.g., TCP/IP, etc.). The gateway 101 may also be connected to a local area 
network (LAN) 120 via an X.25 dedicated circuit, a dial-up TCP/LP connection, or the 
like (161), using any type of transport and connection protocol, such as generic bulletin 
message protocol (GMP), telelocator application protocol (TAP), SMTP, etc. The 
gateway 101 may be connected to the LAN 120 via an access server 125, which will be 
described in further detail later. 

The gateway 101 may also be connected to a facsimile machine 150, or 
equivalent communication device, via a variety of communication mechanisms 151, 
such as via a standard telephone line, etc. 

The kernel of the gateway 101 component of FIG. 1 comprises 3 main daemon 
processes, or subsystems, depicted in FIG. 2. In addition to the service interfaces 204 
(described further later), the kemel processes are: 

1. Manager 202 . Provides database connectivity, message queue 



management, billing interface, and client authentication. 
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2. SMS 203 . Manages interaction with the SMSC 102 via a 
communications protocol (e.g. SMPP for Aldiscon SMS systems, over 
the X.25 or TCP/IP transport protocol). 

3. Watchdog 201 . Ensures that all kernel processes are functioning 
c orr ectl y, which involves constant monitoring of the state of the process 



to ensure maximum system up time. 

10 The Gateway Services and Interface subsystems 204 comprise 5 separate and 

distinct processes, which are usually transient in duration and started on demand by the 
operating system services. The service subsystems are: 

1. SMTP Interface 204A . This service provides the core client message 
15 submission services. All chent and Internet mail (e.g., from the Internet 

140, LAN 120, etc.) eventually use this service to submit messages to 
the messaging kernel 200. 

2. TAP / PET Interface 204B . This service provides a pager protocol 
20 interface for message submission, allowing , paging tenninals, and 

switches to send to GSM mobile phones 130. 

3. POP3 Interface . Although not specifically shown in FIG. 2, POPS is^a" 
protocol component of Internet mail, and is used by cUents to retrieve 

25 Internet mail from a Server. This service is used by the LAN access 
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4. Internet Mail Interface 204C . This service allov^s normal Internet e-mail 
(from 140) to be forwarded to, for example, a digital mobile phone 130, 
and allows for messages to be composed and sent from a mobile phone 
130 to the Internet. 



5. X.25 Conversion Interface . In one embodiment of the present invention, 
there are two available transmission layers supported: x.25 and TCP/IP. 
While the TCP option is primarily referred to in the present 
specification, it will be understood that X.25 may be used as well. The 
X.25 service provides a translation layer to allow incoming X.25 based 
connections to use the TAP, SMTP and POP3 facilities provided by the 
other subsystems. 

The various components of FIG. 3 will now be described: 

• Monitor Services 301 . This service provides a periodic signal to the 
watchdog process to indicate system health. The interval is 

20 programmable at initialization. 

• Billine Services 302 . This service is part of the Manager process 202. 
After all successful messages transfers through the gateway 101, a 
billing record is added to the current billing file. If no file has been 

25 created, a new biUing file, with the current date and time is created and 
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• Database Services 303 . This service provides the interface layer for the 
external datastore 304. This is accomplished using a library of embedded 
5 SQL, such as those provided by Rogue Wave Inc. All access to database 

objects is via the Rogue Wave Library. 



• Oracle Database 304 . An Oracle Workgroup database is used for all 
datastore, including short term queues and long term message store. 
10 Access is achieved Via embedded SQL calls. 



• SMTP Services 305 . This service provides the interface layer between 
the manager process 202 and the SMTP Server (204A). 

' 15 • LAN Services 306 . This service provides the interface layer between the 

manager 202 and the POP3 server 204C. The POP3 server is used by 
the LAN access server 125 to retrieve messages from the mobile phone 
130 destined for the LAN chents 121. 

20 ^ • Sendmail Services 307 . This service provides the interface layer 

between the sendmail application that is used to send Internet emails 
from tiie gateway 101, and the manager process 202. 

• Fax Services 308 . This service provides the interface layer between the 
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manager process 202 and the Fax Server application. Fax messages are 
formed as a system command to a remote computer that hosts the Fax 
Server apphcation. 



Soup Layer 309 . This service provides the interface layer between the 
manager process 202 and the Java based application that is used to 
provi de scr ee ns used to confi g ure and control the g atev^a y ap plicati on 
101. 



2. Addressing Schemes 

One important feature of the gateway system 101 is its ability to route messages 
both from the LAN 120 and/or the Internet 140 to the mobile phone 130, and fi-om the 
mobile phone 130, back to the LAN 120 or Intemet 140 again. To accomplish this, the 
gateway 101 uses the concept of addressing schemes. Addressing schemes are used to 
resolve the inherent differences in the addressing between computer based mail 
systems, and mobile phones. 

On a computer mail system (e.g., on LAN 120), individual users 121 are 
assigned an identifier (usually their name and home domain) which other clients 121 
can use to send mail to them. Mobile phones 130 however only use numbers to identify 
other phone users. To simplify sending messages between mail chents 121 and mobile 
phones 130, the gateway 101 of the present invention can use a number of addressing"" 
schemes and methods to determine the recipient. 
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Messages sent from a computer based mail system to a mobile phone 130 
require a valid MSISDN (mobile phone number), and the UNIX domain name where 
the gateway 101 resides. For example, a valid MSISDN/domain name address might 
be "Error! Bookmark not defined/', where the number "6421200300" identifies the 
5 MSISDN, and "sms.domain.com" identifies the Unix domain name of the gateway 101. 

However, accordin g to the teachin g s of the present invention, messag es sent 

from a mobile phone to a destination (LAN 120, Internet 140, etc.) may be addressed 
using a number of different methods. When a message is sent from an outside e-mail 
10 source to a mobile phone 130, the gateway 101 may create a new, temporary and 
unique reply MSISDN number associated with the reply address, before sending the 
message and the reply MSISDN number onto the mobile phone 130. If the user of the 
mobile phone 130 replies to this message, the reply MSISDN number is sent with the 
reply message back to the gateway 101, which the gateway 101 can map back onto the 
5 e-mail address of the original sender ~ either an Intemet mail address or some other 
type of client ID. Thus, the user of the mobile phone 130 can reply to messages 
without knowing the address of the original sender - the gateway 101 performs all 
necessary mapping. 

0 For messages originating from the mobile phone 130, and not using the reply 

fimction, there are two methods available for determining dehvery. If the message is 
destined for the Intemet 140, the fiill Intemet address of the recipient may be specified 
in the body of the message. The mobile phone 130 then transmits the message to the" 
gateway 101 using a selected Intemet mail relay MSISDN, which is a special number 

> for Intemet mail only. The gateway 101 is configured such that any message sent to 
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this MSISDN number will be forwarded to the Internet 140, and delivered to the 
recipient address specified in the body of the message. 

Messages destined for a client 121 using the server 125 have two additional 
5 addressing options available to them. These options include two addressing schemes 
called number map addressing and number name map addressing. For corporate LAN 

e-mail systems, number map addressin g req uires a permanent MSISD N numbrar be 

semp for each individual chent 121 configured on the system 120. The system 
administrator for the system 120 assigns an additional 2 to 4 digit default ID that is 

.10 tagged onto the permanent MSISDN when messages are sent. These number ranges are 
used to identify the destination cHent 121 to receive the message. Only a portion of the 
overall number is used - the remainder is used by the client 121 to identify the 
individual user within the client mail system 120. For example, if the Gateway client 
ID prefix is "642100200", and the cUent mail user default ID is "01", then the full 

15 originating address would be "6410020001" -- this address is what would be used to 
reply to messages, and to originate mobile phone based messages to the client mail 
system. 



For Internet e-mail and number map addressing, incoming Internet messages 
20 may be assigned MSISDN numbers on an ad-hoc basis fi-om a pool of available 
numbers. This temporary MSISDN is stored with the source address of the Internet 
mail, and is used if the message is replied to. All numbers in this temporary MSISDN 
pool may be reused in oldest first date order. For example, suppose a message comes - 
in from the Internet to a mobile number "6421605600". It may be addressed as 
25 "642 1 60500@sms.bulletin.net" from "anyperson@anothercompany.com". The gateway 
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101 assigns a new temporary MSISDN for the life of the message (e.g., 
"6421001001 1234") and saves the originating address with this temporary MSISDN. 
When a reply from the mobile phone comes back, the destination address 
"6421001001234" is matched to the Intemet address of the original message sender. 
This address ("Error! Bookmark not defined.") is then used to transmit the message 
reply. 

Using the nimiber name map addressing scheme with the server 125 only 
requires the Gateway client ID prefix to be used when transmitting the message from 
the mobile phone 130. This will identify the client 121 to receive the message. Using 
an "aliasing facility" in the access server 125 (described in further detail later), the 
client 121 can then use a simple address like John, or 123 in the body of the message to 
identity the intended recipient. For example, if the gateway client ID prefix is 
"642100200" and the LAN mail user is "johnsmith", the message would be received on 
the mobile phone 130 as from "johnsmith". Messages sent to the LAN 120 from the 
mobile phone 130 would have to be addressed as "TO johnsmith <message body>" and 
"+642 100200" entered as the destination phone number, when requested by the phone. 

Using the number name map scheme with the Intemet 140 requires the mobile, 
phone user 130 to address the Intemet destined message in the body of the message to 
identity the intended recipient. Once the message is address to the intended recipient, 
the message is sent to a predefined, and known MSISDN. This number is referred to as 
a relay nmnber. Messages to this number are checked by the gateway 101 and the"" 
destination address is obtained from the body of the message. Given that some mobile 
phones 130 cannot produce the @ character, substitutes like * and $ can be used. As 
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an example, suppose the Gateway Internet mail relay number is "6421900900" and the 
Internet mail destination is "Error! Bookmark not defined.". The message would be 
received from the mobile addressed to the MSISDN "6421900900". The body of the 
message would contain the address "johnsmith*somecompany.com". 

3. Gateway 101 Object Implementation 



The gateway 101 may be programmed using standard object-oriented 
programming techniques. A description of the various gateway 101 objects, and classes 
10 used to define the objects, is provided below. 

A. Basic System Classes 

The basic system classes are a set of "utility" classes used by many of the main 
15 server object classes. There are 2 timer classes. One is based on the timer services 

provided by the native operating system, which provides second based granularity. The 
other is a time of day trigger class, used to tie specific actions to a particular time of 
day. The period timer class and time of day class are defined below in Tables 1 and 2: 



20 


Period Timer Class 






Object Attributes 






• Interval: Timer delay in seconds. 






• Start Time: Timer start time. 




25 


Object Methods 





<WO 885847eA1_l_> 
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• Lret / bet meinoas lor an attriDUtes. 

• Has Expired: Checks whether the timer has expired. 

• Reset: Resets the start time to the current time. 




5 


Table 1 






Time of Dav Class 




10 

— J 


Object Attributes 

• Day: Which day that time is set for. 

• Time: Time of day in seconds. 






f Ihiprf IVIethnd^i ' ~ ■ — ~ — ' 

• Get / Set methods for all attributes. 

• Has Expired: Checks whether the timer has expired. 




15 


Table 2 

The thread class provides an object-oriented interface to the native operating 
system lightweight processes, or thread interface. All classes using threads will utilize 
this class. The thread class is defined below in Table 3. 




20 








Thread Class 






Object Attributes 

• Status: Threads current status (running or stopped). 

• Start / Stop: Starts or stops the running thread. 

• Kun. 1 ne actual worKer metnoa oi tne tnreaci. 






Table 3 




30 


B. Core System Services Objects 

The Core System Services Objects are a group of persistent server processes. 





These processes provide the implementations for the core service objects. These objects^ 



provide the primary and essential services for the gateway server 101 . The core system 
35 service objects and their containing processes are described below. 
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Each server process has one parent object, which is created at the same time the 
process is created. This object is responsible for the global "process'- initialization, 
termination and any specific initialization or termination on any of the other server 
objects. This object also checks the health of the server objects. Any problems are 
reported to the admin server. The watchdog timer 201 functionality is depicted in FIG. 
3 I n one embodiment, error conditions are reported with the re t urn from fu nction calls. 
There is not a timer implemented in the code for process health. Each process 
maintains a text log file of all debug and diagnostic information for this server process 
and its' contained objects. The detail of information produced is controlled by an 
operating system environment variable. The server parent object is defined below in 
Table 4. 



Server Parent Obtect 
Object Attributes 

• Health Timer: Period timer used to monitor process health. 

• Process Log: A log file for all server process objects to log dialogue, and debug 
information. 

Object Methods 

• Initialize: Perform any process global initialization fimctions. 

• Terminate: Perform any process global termination fimctions. 

• LogMessage: Logs a diagnostic or debug message to the per-process log file. 

Table 4 



The intrinsic data objects, or object datum, are a group of shared C-h- objects. 
They exist purely as the fimdamental datum from which the core gateway 101 object 
services are built. The objects are often passed from object to object and service to 
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service, and generally exist independent of the server process or object instantiation. 
These object datum are not necessarily fine grained, and therefore pass by reference 
semantics should be used when passing them from object to object. 

5 The message object datum contains the details of an individual message. This 

object is defined below in Table 5. 



10 
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Message Object 
Object Attributes 

• Source Address: Full Internet address of sender. 

• Destination Address: MSISDN of destination. 

• Message Text: Contents of the message. 

• Priority: An integer value indicating the priority of the message. 

• DateTime: When the message was received by Bulletin Gateway. 

• Validity: How long before the message expires. 

• Status: Message status information. 

• Bill Rating: The billing method to be applied to this message. 
Object Methods 

• Get / Set Methods for all attributes. 



20 Table 5 

The MSISDN object datums contain the MSISDN (described elsewhere). The 
MSISDN object is defined below in Table 6. 

25 



MSISDN Object 
Object Attributes 

• Source ID: Object ID of the sender object. 

• Destination ID: Object ID of the destination object. 

• MSISDN: The actual MSISDN of this object. 



Object Methods 

» Get / Set methods for all attributes. 

35 Table 6 
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The notification object datums are passed fi-om one object to another to inform the 
target object of some external event (e.g., parameter change, subsystem outage, object 
teraiination, etc.). The notification object is* defined below in Table 7. 



10 



15 



Notification Object 



Object-Attributes- 



Serial ID: An DD unique to the source object. 

• Source ID: Object ID of the sender object, 

• Destination ED: Object ID of the destination object. 

• Time stamp: When the notification was created. 

• Notice: The actual notification code or data. 

• Additional Data: Any extra data. 
Object Methods 

• Get / Set methods for all attributes. 



Table 7 



The Request object is used by the various processes to obtain data fi-om the 
20 manager process 202. The request object is defined below in Table 8. 



25 



Request Object 

• Serial ID: An ID unique to the source object. 

• Source ID: Object ID of the sender object. 

• Destination ID: Object ID of the destination object. 

• Time stamp: When the request was created. 

• Request: The actual request code or data. 

• Require Ack: Whether this request requires an acknowledgment. 



30 Table 8 

Acknowledgment object datums are sent in response to a request. The 
acknowledgment should contain the serial ID of the sender, and be directed back to the^ 
source object. The acknowledgement object is defined below in Table 9. 

35 
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Acknowledgement Object 
Object Attributes 

• Serial ID: The id of the original request / notification object. 

• Source ID: Object ID of the sender object. 

• Destination ED: Object ID of the destination object. 

• Time stamp: When the acknowledgment was created. 

• Complete: Yes or No if the request was completed. 

• Reason: Reason if request was not completed. 
Object Methods 

• Get / Set methods for all attributes. 



Table 9 



Association object datums are used to map one data type to another, such as 

/ ■ * ■ 

15 routing table entries and address mappings. The association object is defined below in 
Table 10. 



Association Object 

Object Attributes 

Source ID: Object ID of the sender object. 
Destination ID: Object ID of the destination object. 
Name: The name associated with this data map if any. 
Type: The type of the data map, ie routing entry or address map. 
Mapl Type: The type for the first map datum. 
Mapl Data: The data for the fu^t datum. 
Map2 Type: The type for the second map datum. 
Map2 Data: The data for the second datum. 
Object Methods 

Get / Set methods for all attributes. 

AsString: retrieves one map datum, converting it to a string. 



Table 10 



The core service object superclass is the base or super class for each of the core 
35 service objects. This class provides the interface used for generic object commvmication 
such as request, notification and acknowledgment passing. All objects must implement-- 
this interface. The core service object superclass is defined below in Table 1 1. 
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Object Attributes 

• Transaction Stats: A statistic object updated internally, and periodically requested. 

• State: Internal object state - Used for debugging. 
Object Methods 

5 • Notify: Send a notification to another object. 

• Request: Send a request to another object. 

• Acknowledge: Send an acknowledgment to another object. 

• Process: Processes any incoming notices, requests, or acknowledgments. 

Table 11 

10 

The manager server 20'2~iniplements tHeoFject mterfaces foT the message, 
queue, billing, MSISDN objects. These objects manage all interfaces to the database. 
All objects in this server process are multi-threaded, with one thread per object 
15 instantiation. All objects are generally one instantiation. 



The message store object is the most basic and fundamental object in the 
gateway server 101. This object contains all the logic related to storing and retrieving 
messages from the data store 304. The message store object is defined below in Table 
20 12. 



Message Store Object 
Object Attributes 

• Message Store: A reference to the data store object. 
Object Methods 

• Store: Saves the message to the data store. 

• Retrieve: Loads a message from the data store. 

• Delete: Removes a message from the data store. 

• Archive: Sends message details to the billing object, and then flags the message as 
sent. ^ , - — _ 

Table 12 

The queue management object maintains the queue tables in the data store. For 
35 each new unsent message added to the message store, an entry is created in the queue 
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data store by this object. Messages are retrieved in order of the message priority and 
submission date. 

Message objects are sent to the sms 203 (FIGS. 2-3) for transmission to the 
SMSC 1 02 (FIG. 1). Sent messages are placed in a holding data store waiting for a 
positive acknowledgment. If a messa:ge submission is not acknowledged by the 
Jieceiying transmitter , and the failu re was not an unrecnverahlft ftrrnr it plarH back 
into the queue data store. Successfully sent objects are archived back to the message 
store object. 

The queue management object is defined below in Table 13. 



Queue Management Obfect 




Object Attributes 

• Queue Datastore: A reference to the data store object. 

• MessageQ Cache: One cache per routing table destination. 

• Sent Messages: A list of messages waiting to be acknowledged. 

• Queue Timer: The master queue timer. 
Object Methods 

• -Next Message: Returns the next available message for transmission. 

• Stop / Start Processing: Starts or Stops the automatic timer processing of queue 
entries. 



The biUing object handles all aspects of the CaU Detail Record (CDR). The 
CDR is used for the integration of call information fi-om a Switch with the billing 
system 302 so an operator can supply a detailed bill to end users. When a message has - - 
been successfully sent the biUing object 302 will be sent the message details. A billing 
record is then created. 




Table 13 
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20 



The billing files created are in the same format as the Aldiscon billing file 
format 2. A description of this billing record may readily be found in the "Aldiscon 
Short Message Peer to Peer Manual". An example of an Aldiscon billing record is 
shown below: 

"Q Q0Q99C0Q 1 2 8C0000000000642 1 0 1 0088 642 1 0 1 0 1 OOP 1 3 290 0000 1 C00000OOO0Q642 1 632 592 
O0OOO0O0OOO0OO0C98O5O5O01344012CO00C . 01600C0C0C000" 

The billing object 302 is defined below in Table 14. 



Billing Object 
Object Attributes 

• Bill Datastore: A reference to the data store object. 
Object Methods 

• Create CDR: Creates a CDR record fi-om the supplied message. 



The sms server object 203 implements the object interfaces for the various sms 
and paging protocol objects such as Smpp for Aldiscon SMSCs and Sema Open 
Interface for Sema SMSCs. In either case, the actual object interface remains the same 
— only the actual implementation details differs. 

Messages are forwarded to the sms 203 for transmission via the selected transport 
protocol. The sms object 203 must then acknowledge all messages as having been 
successfully sent, failed to send,, or un-sendable. The various responses will depend on 
the response firom the SMSC 102 when a submission was attempted. Messages are 
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20 



25 



attempted once only, as retries are handled by the Queue manager object in the manager 



The sms object 203 is also responsible for starting and maintaining the physical 
link, and any protocol management required by the various SMSCs 102. 



The SMS object 203 implements the actual native commimication protocol of the 

host SMSC 102. The current alternatives are SMPP on an Aldiscon SMSC or the Sema 
Open Interface protocol for a Sema SMSC. The SMS object is defined below in Table 
15. 



SMS Object 
Object Attributes 

• SMS Interface: A communication link to the SMS. 

• Unconfirmed Messages: A list of messages sent to the SMSC but not yet confirmed. 

• Un-sent Messages: A list of messages received fi-om the router but not yet sent to 
the SMSC. 

Object Methods 

• Start / Stop: Starts or stops the link between the object and the SMSC. 

• Submit: Submits a message for transmission to the SMSC. 

• Receive: Sends a incoming message received fi-om the SMSC to the manager. 



The sms object 203 may be initiahzed as follows, with reference to FIG. 11. The 
reference numerals shown below in [brackets] correspond to the associated reference 
numerals in FIG. 11. 



server 202. 



[1101] 



Read the configuration file and store the system parameters 
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required to log into the SMSC 102. Information includes ports 
used for transmit/receive, password, usemame and message type. 
[1 102] Open the transmit port for communication of messages to the 

SMSC 102. 

5 [ 1 1 03] Check for successful transmit port initialization. 

[ 1 1 04] Test for requirement for two-way communication. If two-way, 

o pen receive port, otherwise skip to next section (1 107 ). 

[ 1 1 05] Open the receive port for communication of messages from the 

SMSC 102. 

10 [ 1 1 06] Check for successful receive port initialization. 

[ 11 07] Send bind request to the SMSC 1 02 for the transmit port. 

Information includes usemame, password, message type, etc. 
[1 108] Check for successful bind. A bind acknowledgement should be 

received from the SMSC 102 over the specified port. 
15 [ 1 1 09] Test for requirement for two-way communication. If two-way 

communication, attempt to bind using the receive port, otherwise 
skip to the next section (1112). 
[1110] Send bind request to the SMSC 1 02 for the receive port. 

Information includes usemame, password, message type, etc. 
20 [1111] Check for successful bind. A bind acknowledgement should be 

received from the SMSC 102 over the specified port. 
[1 1 12] Exit with TRUE, indicating successful bind of the gateway 101 

into the SMSC 102. 
[1 1 13] Exit with FALSE, indicating unsuccessful bind of the gateway 

25 101 into the SMSC 102. 
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The admin server implements the object interfaces for the task scheduling, 
parameters, statistics, and alarm monitoring objects. These objects monitor and check 
the status of the server as a whole, and provide dynamic access to the runtime 
5 parameters. 

The tas k scheduler ob j ect mana g es a list of tasks that need to be run periodically . 

The tasks may include bill file creation, statistics gathering, and health monitoring. 

Each task is scheduled either as a period timer, or as a time of day timer. As each task 
0 timer expires, a request is sent to the destination object requesting that the task be 

completed. If a task fails to complete a notification is sent to the alarm object and the 

task is rescheduled. Task timer details are retrieved fi-om the parameter object. The 

task scheduler object is defined below in Table 16.. . 



Task Scheduler Object 

Object Attributes 

• Task List: The Ust of tasks. 

• Timer List: The list of timers associated with task. 
Object Methods 

• Start / Stop: Starts or stops the task scheduler. 

• Send Task Notice: Sends a task request to an object. 

• - Send Failure Notice: Sends a task failure notice to the alarm object. 



The parameter object maintains the central gateway database of preferences and 
options. Each object can request the value for a parameter or update its value. The 
parameter object is also responsible for loading and saving this file. Each individual 
parameter is stored in the form of a key and value pair. String, numeric, and boolean 



Table 16 
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value types may be supported. The parameter object is defined below in Table 17. 



Parameter Object 
Object Attributes 

• Parameter List: The list of key/value pairs. 
Object Methods 

• Save: Saves the values the parameter list to the parameter file. 

• Load: Loads the Key / Values fi-om the parameter file. 

• Get Value: Returns the value for the specified key. 



Table 17 



The alarm object responds to alarm notifications fi-om any other object and 
maintains a health check on all server objects. Any object failure is logged to an alami 
15 log file, and sent to the admin server to be displayed. Alarms are considered active 
until either a cancel alarm notice is received fi-om the originating object or an 
acknowledgment is received fi-om a system administrator via the administration tool 
interface. The alarm object is defined below in Table 18. 



20 



25 



30 



Alarm Object 
Object Attributes 

• Alarm List: A list of active alarms. 
Object Methods 

• Open / Close Log: Opens or Closes the alarm log file. 

• Acknowledge Alarm: Flags an alarm as acknowledged and removes it firom the 
active alarm list. 

• Send Alert: Sends an alarm alert to the admin for display. 



Table 18 

The address resolver object takes care of the details of mapping Internet addresses 
to MSISDN based addresses, as described elsewhere. This mapping is handled by 
association objects, and the general store object. The address resolver is passed 
incorrectly addressed messages fi-om the router object. The resolver then either looks 
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up the correct destination address for the destination type (mobile network or Internet) 
or creates a new mapping for new messages. 

The address resoiver object has an address range that is used to assign temporary 
5 MSISDN-based addresses to outbound Intemet messages. This address acts as a source 
address to the mobile network, and provides a way for the router to find the correct 

source address if the messa ge is re plied to. Source MSISDN addresses, creat ed in real 

time in this manner, live only as long as it takes to cycle through the complete range of 
available addresses. 

10 

AH incoming messages from the mobile network are routed through a requester 
object. The destination and contents of the message are inspected and compared to a 
list of delivery services. Delivery services are keyed to a specific 'known' destination 
address, or to specific instructions contained in the body of the message. For messages 

15 sent to a knovra address, the complete message is forwarded to that service for delivery. 
Messages containing instructions usually relate to another message, and this second 
message can be found based on the destination address of the mobile message using the 
address resolvers source address method. Once this second message is retrieved, the 
request action can be carried out by the deUvery service. 

20 , 

Delivery services consist of an optional "known" address and either an internal 
delivery mechanism, or a pointer to an extemal delivery agent. Intemal agents are 
defined as an intemal method or set of cooperative methods used to complete the 
delivery fimction. Examples of this are a mail delivery agent. Extemal agents are 

25 usually defined as an extemal process or script. 
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Messages containing instructions are usually in the form of commands. These 
commands identify the delivery agent, and or any additional instructions to be passed to 
the delivery agent. These commands can be used to complete complicated instructions, 
5 or to spawn a series of commands to complete a function. 

An example of this is the FX command which instructs the fax extemal delive r y 



10 



20 



25 



agent to fax a message to the supplied fax niraiber. Additional commands and agents 
can be added at any time. 

C. Transient System Server Objects 



The transient system services objects are a group of non-shared server processes. 
These processes provide the implementations for the transient service objects. These 
15 servers provide the extemal communications objects for the gateway server 101 . 

The smtp object 204A (FIGS. 2-3) implements the object interfaces for the SMTP 
receiver object 305. This object implements the SMTP protocol for extemal message 
submission by Internet mail compatible systems. 



In the SMTP object 305 is implemented a full server side version of the SMTP 
protocol as defmed in the Internet RFC 821 and succeeding standards documents. This 
server object is used by both the access server 125 (FIG. 1) and any Internet mail 
clients for message submission. 
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Each individual message is validated against the MSISDN database for authority 
to send, resource hmits etc. Therefore as each message is received from the SMTP 
cHent, a request to the manager server 202 for the MSISDN verification for that 
message must be received and checked before any acknowledgment can be sent back to 
the SMTP chent. The MSISDN to be checked is obtained in the RCPT TO: field where 
the destination will be in the form of "RCPT TO: someuser@somedomain.com". 
Invahd MSISDN message should be rejected during the SMTP transaction. Accepted 
messages are then passed to the manager object 202 for transmission. 



10 Internet mail extension headers, referred to as X headers, are used to control 

certain message properties. Properties controlled by the x headers are Priority, message 
lifetime or validity, and the billing method to be used. An additional 'service provider' 
X header is used to identify clients with special privileges or rights. 



15 



The SMTP Object is defined below in Table 19. 



20 



SMTP Object 
Object Attributes 

• Profile List: A list of the most resent MSISDN profiles received. 
Object Methods 

• Send Message: Sends a message on to the router object for delivery. 

• Reject Message: Rejects a message during SMTP transaction. 

• Smtp Process: Processes incoming SMTP transactions. 



25 



Table 19 



The mail object implements the object interfaces for the POPS transmitter object 
(described elsewhere). This object implements the POPS protocol for external message 
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The POPS object responds to any incoming POPS mail requests. POPS client 
authentication consists of a usemame, which is the MSISDN, and a password. Once 
5 this has been received from the client the POPS object gets the MSISDN objects from 
the manager server 202 to authenticate the transaction. Authenticated sessions can then 

proceed to receive mail. Any invalid user/ pa ssword combinations will result in session 

termination. 

10 After the POPS chent as logged off the successfully sent messages are removed 

from the message object store. 



The POPS object is defined below in Table 20. 



15 POPS Object 

Object Attributes 

• Sent Messages: A list of successfully sent messages to be deleted. 
Object Methods 

20 • Send Message: Sends a message on to the POPS client object. 
PopS Process: Processes incoming POPS transactions 

End Session: Performs end of session cleanup, such as sent message deletion. 

Table 20 



25 The aim object implements the object interfaces for a generic TCP/IP based 

protocol for advanced message submission and reception by external applications. The 
aim object responds to incoming TCP requests on an assigned port. Using the INET 
service daemon, incoming calls cause the DSTET daemon to start this process. The object 
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implements a generic 3 phase protocol (bind, transaction, terminate), that perform the 
same functionality as the SMTP and POP3 protocols combined. Each packet consists 
of a header and data. Each connecting host must be authenticated in a similar manner 
to the POPS authentication ~ that is MSISDN/password. Once authenticated, the client 
can proceed with message submission until either side terminates the session. The Aim 
object will generally only terminate a session if resource limits are exceeded or if a 
s ystem outa g e occurs. 



The aim object is defined below in Table 21. 



Aim Object 
Object Attributes 

• Profile List: A list of the most resent MSISDN profiles received. 

• Sent Messages: A list of successfully sent messages to be deleted. 
Object Methods 

• Send Message: Sends a message on to the manager object 202 for transmission. 

• Get Message: Allows the chent to receive any waiting messages. 

Table 21 



The tap object implements the object interfaces for a TAP alphanumeric paging 
protocol for message submission. The tap object implements a full server side version 
of the TAP protocol. This interface is for use by any client page submission software. 
Given that most TAP client software supports direct dial-up connections, supporting a 
TAP interface would require a modem pool or temiinal servers and local points of 
presence. The TAP interface requires direct management of the client connect and 
login process, and it is therefore necessary to use the S VR4 service access controller 
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With the tap object, each individual message is validated against the MSISDN 
database for authority to send, resource limits etc. Therefore as each message is 

5 received from the SMTP client, a request to the manager server 202 for the MSISDN 
profile object for that message must be received and checked before any 

acknowledgment can be sent back t o the TAP client. The MSISDN to be check i s 



obtained from the message destination field. Invalid MSISDN message should be 
rejected during the transaction. Accepted messages are then passed to the router object 
10 for transmission. 

The tap object is defined below in Table 22. 



15 



20 



Tap Object 
Object Attributes 

• Profile List: A list of the most resent MSISDN profiles received. 
Object Methods 

• Send Message: Sends a message on to the router object for delivery. 

• Reject Message: Rejects a message during SMTP transaction. 

• Tap Process: Processes incoming SMTP transactions. 

• Get Profile: Gets a profile from the manager profile store object. 



25 



Table 22 

4. Operation of the Gatewav 101 

FIGS. 4-10 depict the processes performed by the gateway 101 in order to 
implement the present invention. All the steps shown in these figures reference the 
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various servers and objects they contain using the s>mtax of <Server process>::<Object 
Name>. Additionally, the reference numerals shown below in [brackets] correspond to 
the associated reference numerals in the various figures. 

5 With reference to FIG. 4, a process for submitting a message fi-om a mail cUent 

121 to the router object for transmission is shown, as described below: 



[401] SMTP connect request from mail chent 121. INET service starts 

smtp::SMTP object 

10 [402] smtp::SMTP exchanges SMTP greetings with client 121, and 

mail transactions begin. 
[403] Chent 121 submits a mail message to a MSISDN. 

[404] SMTP Object requests the MSISDN object from the 

manager: iMSISDN object. 
15 [405] manager: :MSISDN retrieves the MSISDN from the MSISDN 

data store. 

[406] manager: :MSISDN returns either a success, or an error. 

[412-413] On error, smtp::SMTP reports and error to the client. 
[407-4 1 1] . smtp: :SMTP sends a complete message to manager: :Router for 
20 transmission. 

With reference to FIG. 5, a process for routing a message to the destination 
object for transmission to the final target SMSC 102 is shown, as described below. 

25 [501-503, 507-508] manager: :Router receives a message, and extracts the 
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destination address. 

manager iRouter passes the message to the destination 
transmitter object. 

If the transmission object was not active then 
manager: :Router passes the object to the 
manager: : Qmanager. 



10 



15 



20 



With reference to FIG. 6, the steps described below illustrate the process for 
maintaining the queue of messages waiting to be sent. 

[60 1 -602] manager: :Qmanager checks with manager: :Message whether the 
message exists in the data store. 

[603] If not manager: :Message adds it to tiie data store. 

[604-607] manager: :Qmanager adds the message to the waiting queue, if it 
is not aheady present. If there are less than the message queue 
cache size, the message is added to the queue cache for the 
transmitter object, manager: :Qmanager cycles throughout the 
various queue caches for each queue, 

[608-609] manager: :Qmanager sends the top message to sms: :Router. 

[610] manager: :Qmanager adds the message to the sent messages 

cache. 

[611] manager:: Qmanager checks the timestamps on all entries in the 

sent message cache. All old entries that have not been 
acknowledged are placed back in the message store. 



25 
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With reference to FIG. 7, the steps described below illustrate the process for 
transmission of a message to the final destination. 



[701] manager: :Router passes a message to the designated active 

(SMS) transmitter. 

[702] sms:SMS packetises and sends the message to the SMSC 1 02. 

_ [703 ] _ sms:SMS adds the message to a sent messa ges queue^ 



[704] sms::SMS receives an acknowledgment fi-om the SMSC 102. 

[705] sms::SMS checks this acknowledgment against the hst of sent 

messages. The matching entry is removed fi-om the sent 

message cache. 

[706] For both positive and negative SMSC acknowledgments an 

acknowledgment object is created and sent to the 
manager: :Qmanager. 

^ ^ [707] For positive acknowledgements, manager: :Qmanager removes 

the message from the sent queue. 
[708-709, 713] manager: :Qmanager informs manager: :Message that the 

message can now be archived. 
[710-71 1, 713] For negative acknowledgments manager::Qmanager will 
20 remove the message from the sent messages cache and add it 

back into the queue data store. 
[712-713] If the negative acknowledgment was a permanent one 

manager: :Qmanager removes the message from all queues. 
[712-713] manager: :Qmanager then passes a request for a ^^transmission 
25 failure" message to admin: : Alarm for processing. 
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With reference to FIG. 8, the steps described below illustrate the process for 
receiving a message from the SMSC 102, and performing the required action for final 
delivery. 

[801 ] sms::SMS receives and acknowledges a delivery request from 

^the,SMS_C-l.Q2. 



[802] sms::SMS passes the message to manager: :Reqestor. 

[803] manager: iRequestor examines the destination address against the 

Ust of delivery services. 
[803] If there is a match, manager: :Requestor passes the message to the 

delivery agent for processing (806) 
[804] If there is no a match on deUvery address, manager: :Requestor 

parses the body of the message looking for any text "keys" that 

match any of the delivery agent keys. 
[805] If there is a match manager: :Requestor passes the message to the 

delivery agent for processing (807). Otherwise, to step 811. 
[807] Delivery Agent processes message for delivery. 

[808] If there was a match on either manager: :Requestor passes the 

message details to manager: :Bill. 
[809] manager: :Bill generates a Call Detail Record (CDR), and passes 

the message to manager: :Message. 
[807] manager: :Message archives the message in the data store. 

[806] If no match was found, manager: :Requestor passes the message 

to manager: :Router, where a system "non-dehvery " message is 
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generated. 

[811] Process non-delivery message. 

With reference to FIG. 9, the steps described below illustrate the process for 
5 transmitting a message destined for the SMSC 1 02, but which for some reason fails to 
be transmitted successfiiUy, and the failure is deemed permanent. 



10 



[901] sms::SMS sends a 'transmission failed' message to 

admin:: Alarm. 

[902] admin:: Alarm logs the details of the message failure into the 

system log. 

[903] admin:: Alarm constructs a new "failed to transmit" message to 

the source address of the message, 
[904] admin:: Alarm passes the new message to manager: :Router to 

15 send. 

With reference to FIG. 10, the steps described below illustrate the process 
involved with a client's 121 connection to the gateway 101 to receive waiting 
messages, or rephes. 
20 . 

[1001] POPS connect request from mail client 121. DsTET service starts 

mail: :M AIL object. 

[ 1 002] mail: :MAIL exchanges POPS usemame and password with client^ 

121. 

25 [lOOS-1004] mail::MAIL requests the MSISDN object from the 
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manager: iMSISDN object. 
[1005-1006] manager::MSISDN retrieves the MSISDN from the MSISDN 

data store, manager: iMSISDN returns either a MSISDN object, 

or an error. On error mail::MAIL reports and error to the client, 

and terminates the connection. 
[ 1 007- 1 008] mail: :MAIL checks the password and profile for a mail service 
and resource lirpitatinns Tf the target MSI SDN h as a mail 



service and not exceeded resource limits the transaction 
proceeds, otherwise an error is returned to the client 121. 
10 [1009-1010] smtp::SMTP sends a complete message to manager: :Router for 

transmission. 



5. LAN Access Server 125 and Clients 121 

15 As described previously with respect to FIG. 1 , the LAN access server 125 of 

the present invention provides for the transparent forwarding of e-mail from a client 
121 on a LAN 120 to a mobile phone 130 (e.g., a PCS mobile phone) via the gateway 
101 . Additionally, as a ftirther feature of the present invention, the LAN access server 
1 25 may also interface to, for example, an appointment and task management system 

20 (such as Microsoft Scheduler*-, or the like) operating on the server 125, LAN 120 and 
client 121, to provide automatic forwarding of appointment reminders, task reminders, 
etc., to a mobile phone 1 30. 

In a preferred embodiment, the software applications implemented on access 
25 server 125 in order to implement the teachings of the present invention may be . 
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complied as 32-bit C-h- code to operate with, for example, any of the following 
operating systems: Windows 95, Windows 98, Windows NT (3.51 and 4.00 
Workstation and Server), or equivalent. Of course, any other suitable operating system 
may also be used. The access server 125 itself may therefore be any suitable hardware 
platform that supports these or any other chosen operating system. For example, in one 
embodiment, access server 125 may comprise a Pentium PC (IBM compatible), with 
the Window s NT 4.0 Workstation Operatin g System ( or eq uivalent). The s oftware of 
the present invention that controls the operation of access server 125 may be designed 
to be compatible with MAPI (Exchange and MS Mail), VIM (Lotus Notes and 
CCMail), MHS, or any other suitable protocol. Also, the following application 
programming interfaces (APIs) may be used in one embodiment: Microsoft Foundation 
Classes, Extended MAPI, Remote Access Server (RAS), Winsock, and Remote 
Procedure Call (RPC). 

With reference to FIG. 1, in one embodiment, the access server 125 and clients 
121 operate as three general components in a client/server architecture. The basic 
components include the access server 125 itself, as well as a client. administration tool 
that operates on a client 121 and a server administration tool that operates on the access 
server 125. The server 125 and clients 121 may communicate with one another via 
RPC calls over the LAN 120, such as through the TCP/IP protocol, or any other 
suitable protocol. 

FIGS. 12-21 are flow diagrams depicting the various steps performed by the ~ 
LAN Access Server 125 in order to process mail between one or more clients 121 of the 
network 120 and one or more phones 130, through the intervening components 
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(gateway 101, SMSC 102, switch 103, etc.). These figures are described in detail 
below, and again the reference numerals shown below in [brackets] correspond to the 
associated reference numerals in the figures. 

FIG. 12 describes an overall process performed by LAN Access Server 125. 



[ 12011 Initialize the system, including setup of the timer for mail system 

polling and gateway 101 access (fiuther details in FIG. 13). 



10 [1 202] Backup user database, forward e-mails, and contact Gateway 

101. This is a main "artery" of the system (fiirther details in FIG. 
14). 

[1203] Clean up and exit the system (further details in FIG. 15) 



15 



FIG. 13 depicts the process performed by step 1201, described above with 
respect to FIG. 12. 

[1301] Check previous instance. 



20 



[1302] Bring up the old instance. 

[ 1 303] On the video display of LAN Access Server 1 25, show the 

startup-splash screen, create main window (but not show it), 
25 setup the timer, initialize the Send Queue and the Reply Queue. 
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[1304] Create the Server Thread. 



[1305] Create the Gateway Thread. 



[ 1 306] Create the Mail Processing Thread. 



[1307] Shut off the startup-splash screen, show the main window. 

10 FIG. 14 depicts the process performed by step 1202, described above with 

respect to FIG. 12. 

[1401] ; Check disk space. 



15 [1402] If low, show a suitable warning and put the program in standby 

mode. 

[1403] Check if it is time to back up the user database. 

20 [1404] If so, send a Windows message to Mail Processing Thread to 

back up the user database. 

[ 1 405] Check if it is time to connect to the gateway 101. 

25 [1405A]. If so, then signal gateway thread for sending mail to and polling 
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mail from the gateway 101 . This step is described in further 
detail with respect to FIG. 16. 

[1406J Check if it is the time to process mail. 

5 

[1406 A] If so, then signal mail thread for mail processing. This step is 
described in further detai l with re spe ct to FIG. 17. ... 



FIG. 15 depicts the process performed by step 1203, described above with 
10 respect to FIG. 12. 

[1501] On the video display of LAN Access Server 125, show the shut 

down splash screen. 

15 [ 1 502] Stop the Server Thread. 

[1503] Stop the Gateway Thread. 



[1 504] Stop the Mail Processing Thread. 



20 



[1 505] Save the messages in Send and Reply Queues to a file. 

[1506] Shut off the shut down splash screen and the main window, 

25 FIG. 16 depicts the process performed by step 1405 A, described above with 
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10 



[1600A] 
[1600B] 
[1601] 



[1602] 
[1603] 



[1604] 
[1604A] 



If there are messages in the Send Queue or two-way mode, and 
PPP dialup is enabled, then do the PPP dial up. 

Try to connect to the POP3 mailbox 204C at the gateway 101. 

Retrieve all messages from the POPS mailbox 204C at the 



15 



gateway 101 and put them into the Reply Queue. 
Try to connect to the gateway 101 using SMTP protocol. 
Retrieve each message from Send Queue and send it to the 
gateway 101 . This step is described in further detail with respect 
to FIG. 21. 

Disconnect from the gateway 101. 



[1605] 



FIG. 17 depicts the process performed by step 1406 A, described above with 
respect to FIG. 14. 



20 



[1 701] Get the user database and take the first user. 

[1701 A] Process mail for this user. This step is described in further detail 

with respect to FIG. 18. 
[1702] Get the next user. 



25 FIG. 1 8 depicts the process performed by step 1 701 A, described above with 

respect to FIG. 17. 
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Start a MAPI session for the xisen Open a MAPI session by 
means of the user's mail profile; open the user's address book, 
open the user's mail store and all standard mail folders, and open 
the "forward" and the "forwarded" folders created by the LAN 
Access Server 125 for the user. 

Call the MAPI Flush function to send out all messages in the 
"Outbox" folder and get all incoming message s to the "Inbox" 



folder. 

[ 1 802 A] Send out replies for this user in the Reply Queue. This step is 
described in further detail with respect to FIG. 19. 

[1803] Move all messages firom the user's "InBound" directory to the 

"forward" folder. 

[ 1 803 A] Check the user's "Inbox" folder and move messages to 

"forward" folder. This step is described in further detail with 
respect to FIG. 20. 

[ 1 804] Copy all messages in the user's "forward" folder to Send Queue. 

[1805] Move all messages in the "forward" folder to "forwarded" folder. 

[ 1 806] Check Schedule+ (or equivalent calendaring and appointment 

software package) for occurrences of appointment, task and 

event. Create messages according to the information obtained 

and put the messages in the Send Queue. 
[ 1 807] Send synchronization messages from the user's "Inbox" and 

"Sent" folders to the "OutBound" directory. 
[ 1 808] Logoff from the MAPI session. 
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FIG. 19 depicts the process performed by step 1802A, described above with 
respect to FIG. 18. 



[1901 ] Take the first message from the Reply Queue 

[1902] If there is not a message in the "forwarded" folder corresponding 

to this reply, or if there is then if this is a rejected message, then 
generate a Non«Delivery Notice for the message and put the 

notice into the user's "Inbox" folder. 



[1903] If this is a reply to an originated message, then put the reply into 

10 the user's "Inbox" folder. 

[ 1 904] Otherwise, put the reply into the user's "Outbox" folder. 

[ 1 905] Get next message. 

FIG. 20 depicts the process performed by step 1803 A, described above with 
15 respect to FIG. 18. 

[2001] Get the first unread message from the user's "Inbox" folder. 

[2002] If the message's delivery time is not earlier than the cutoff time, 

and the message has not been forwarded before and the messages 
20 passes the filter, then move the message to the "forward" folder. 

[2003] Get the next message. 

FIG. 21 depicts the process performed by step 1604 A, described above with ^ 
respect to FIG. 16. 

25 
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[2101] Get the first message fi-om the Send Queue. 

[2 1 02] Send this message to gateway 101. 

[2103] Put the message back into the Send Queue. 

[2 1 04] If no sending error occurred but the message is rej ected by the 

5 gateway 101, then mark the status of the message as rejected and 

put it to the Reply Queue. 
[21-05.] Get.the^next.message. 



The present invention has been described previously in a preferred embodiment. 
10 It will be understood by those having ordinary skill in the art that the present invention 
may be implemented in a variety of ways, while still remaining within the scope of the 
claims set forth below. 
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A messaging system comprising: 

(a) a wireless communication device; 

(b) means for originating an electronic message including: 

(i) a destination address, in a first format, associated with the 

wireless communication device; and 

(ii) a reply address, in a second format, associated with the 
originating means; 

(c) means for performing the steps of: 

(i) receiving the electronic message from the originating means; 

(ii) creating a temporary reply address, in the first format, associated 
with the reply address of the electronic message; 

(iii) forwarding a modified electronic message to the wireless 
communication device, wherein the modified electronic message 
includes as a reply address the temporary reply address; 

(iv) receiving from the wireless communication device a reply 
electronic message including the temporary reply address; and 

' (v) forwarding the reply electronic message to the originating means 
whose reply address is associated with the temporary reply 
address. 

The messaging system of claim 1, wherein the wireless communication device 
comprises a digital mobile phone. 
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3. The messaging system of claim 1, wherein the originating means comprises a 
chent/server system. 



4. The messaging system of claim 1, wherein the originating means comprises a 
mail server on the Internet. 



.5.. . . _The, messaging system of clai m 1 , wherein th e first format corre sponds to an 
MSISDN address. 



6. The messaging system of claim 1 , wherein the second fomiat corresponds to an 
Internet address. 

7. A messaging system comprising: 

(a) means for originating an electronic message including a reply address 
associated with the originating means; 

(b) means for wirelessly transmitting the electronic message; and 
(a) a wireless communication device for performs the steps of: 

(i) receiving the wirelessly transmitted electronic message; 

(ii) generating a reply message in response to the receipt of the 
electronic message; and 

(iii) wirelessly transmitting the reply message back to the originating 
means. 

8. A messaging process for use v^ath a wireless communication device, comprising 
the steps of: 
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(a) originating an electronic message including: 

(i) a destination address, in a first format, associated with the 
wireless communication device; and 

(ii) a reply address, in a second foraiat, associated with the 
originating means; 

(b) creating a temporary reply address, in the first format, associated with 
— the repl y address of the electronic messa ge: 

(c) forwarding a modified electronic message to the wireless 
communication device, wherein the modified electronic message 
includes as a reply address the temporary reply address; 

(d) receiving from the wireless communication device a reply electronic 
message including the temporary reply address; and 

(e) forwarding the reply electronic message to the reply address associated 
with the temporary reply address. 

9. A messaging process for use \yith a wireless communication device, comprising 
the steps of: 

(a) originating an electronic message including a reply address; 

(b) • wirelessly transmitting the electronic message; and 

(c) receiving the wirelessly transmitted electronic message at the wireless 
communication device; 

(d) generating a reply message in response to the receipt of the electronic 
message at the wireless commixnication device; and ^ 

(e) wirelessly transmitting the reply message back to the reply address. 
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11. 

15 

12. 
13. 

20 

14. 

25 15. 



An electronic message forwarding system comprising: 

(a) a wireless communication device; 

(b) means for storing a database of records, each record including an 
associated date and time; 

(c) means for periodically polling the records in the database, wherein the 
current date and time is compared with the date and time stored in the 

^database_forj5ach_recp.rd; :_ 

(c) means for forwarding an electronic message corresponding to a selected 
record of the database to the wireless commxmication device, if the date 
and time associated with the selected record matches the current date 
and time, according to pre-selected criteria. 

The system of claim 10, wherein the wireless communication device comprises 
a digital phone. 

The system of claim 10, wherein each record includes a task associated with a 
user of the storing means. 

The system of claim 10, wherein each record includes an appointment 
associated with a user of the storing means. 

The system of claim 10, wherein the database of records is associated with an 
appointment and task scheduler. 

An electronic message forwarding process for use with a wireless 



49 



SUBSTITUTE SHEET (RULE 26) 



BNSOOCIO: <WQ 9a5B47eA1 I > 



wo 98/58476 PCT/US98/12536 



communication device, comprising the steps of: 

(a) storing a database of records, each record including an associated date 
and time; 

(c) periodically polling the records in the database, wherein the current date 
and time is compared with the date and time stored in the database for 
each record; 

-(?)_ fonvardin g an glectronic message corresponding to a selected record of 



the database to the wireless communication device, if the date and time 
associated with the selected record matches the current date and time, 
10 according to pre-selected criteria. 

16. A message forwarding system comprising: 

(a) means for originating an electronic message; 

(b) means, coupled to the storing means, for printing electronic messages; 
15 (c) processing means for: 

(i) storing the electronic message, and 

(ii) responsive to the receipt of a forwarding signal, forwarding the 
electronic message to the printing means; 

- (d) means for wirelessly transmitting the electronic message; and 
20 (e) a wireless communication device for performing the steps of: 

(i) receiving the wirelessly transmitted electronic message; and 

(ii) transmitting the forwarding signal to the processing means, 
thereby causing the processing means to forward the electronic ^ 
message to the printing means. 

25 
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1 7. The system of claim 16, wherein the printing means comprises a fax machine. 

18. The system of claim 16, wherein the wireless commimication device comprises 
a digital phone. 

5 

1 9. The system of claim 16, wherein the printing means is coupled to the process 
means by a telephone network. 
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